Fix module-loader cache expiry and concurrency - #1753

Summary

Frequent cache hits could keep module configuration cached indefinitely.
Concurrent cache misses could also start duplicate queries, and queries
that completed after invalidation could repopulate the cache with old results.

• Stop extending the TTL on cache hits.
• Share one in-flight resolution for concurrent misses with the same key
  within each loader instance.
• Prevent invalidated resolutions from repopulating the cache or removing
  newer pending work.
• Read cached values with a single get and log the cache size before clearing.

Related: constructive-io/constructive-planning#1693 (F11).

Behavior

The existing databaseId / optional apiId key, invalidate(databaseId?) API,
default 60-second TTL, and default 100-entry cache limit are retained.
TTL resolution uses the lru-cache default.

undefined results and PostgreSQL 42P01 results remain uncached.
Other resolution errors continue to propagate.

Invalidation does not cancel running queries: existing callers may still
receive their results, but those results cannot repopulate the cache.

Validation

• All 119 express-context tests passed across 8 suites.
• Full CI passed: 17/17 jobs on e71a1910b7e2.
• Tests cover cache isolation and reuse, concurrent coalescing, invalidation
  races, capacity limits, uncached absence, error propagation, and registry
  forwarding.